Interactive debugging system with debug data base system

ABSTRACT

An interactive system for debugging programs in which a persistent data base system responds to update queries containing debugging information from a debugging information source and to read queries on the debugging information from an interactive interface. The interactive interface produces the read queries in response to inputs from users and formats the results of the read queries as required by the user. One source of inputs is a standard Web browser for which the interactive interface functions as a Web server. The system also includes a command channel by which the source of debugging information receives commands from the interactive interface. In one embodiment, the command channel is implemented in the data base. In a disclosed implementation, the source of debugging information provides memory debugging information. Also disclosed are techniques for using an automatic memory management system to reduce memory fragmentation and heap footprint size.

CROSS REFERENCES TO RELATED APPLICATIONS

The present application claims priority from the provisional applicationU.S. Ser. No. 60/063,992, Michael Spertus, Debugger with web browserinterface, filed Oct. 29, 1997.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention concerns interactive programming tools generally and morespecifically concerns interactive program debuggers.

2. Description of the Prior Art

Debuggers are tools used by programmers to determine what is going onwhen a program is executed. A debugger typically permits a programmer tostart and stop the program's execution and to examine the state of thememory (including hardware registers) being used by the program. Moderndebuggers are interactive: that is, a programmer can input a command tothe debugger and see the effects of the command within a relativelyshort period of time. Modern debuggers can further relate what theprogrammer does and sees to the source code for the program beingdebugged. Thus, if the programmer wants to examine the contents of acertain variable, he or she can select the variable by name and thedebugger will show the programmer the contents in a form thatcorresponds to the type of the variable. Similarly, a trace of calls tosubroutines made by the program and returns therefrom will display thenames of the subroutines being called and returned to. Two examples ofstate-of-the-art debuggers are the BoundsChecker™, manufactured byCompuware Corporation , and Purify, manufactured by Rational Software.Further information about BoundsChecker may be found atwww.numega.com/library/doc.shtml, which in October, 1998 contained thecomplete documentation for the debugger. Further information aboutPurify could be found in October, 1998 atwww.rational.com/support/techpapers. In addition, the Purify debugger isthe subject matter of U.S. Pat. No. 5,535,329, Reed Hastings, Method andapparatus for modifying relocatable object code files and monitoringprograms, issued Jul. 9, 1996. A general discussion of debuggers may befound in Jonathan B. Rosenberg, How Debuggers Work, Algorithms, DataStructures, Architecture, Wiley 1996.

While any modern debugger is useful, debuggers would be more useful ifthey offered more flexible user interfaces. As it stands, debuggers havetwo ways of providing the user with information: by means of aproprietary interactive user interface which communicates directly withthe debugger as it executes the program and by means of a log file, thatis, a text file which contains a list of the interactions between theuser and the debugger. Problems with this arrangement include first,that the interactive user interface can only be used to analyze thecurrent execution of the program; information about past executions iscontained in the log file, and that requires other tools to read it. Asecond problem is that the proprietary user interface requires that theuser interacting with the debugger have the interface software and alsolimits the user to the kind of interaction dictated by the proprietaryuser interface. As for the log files, nothing can be done with the logfile beyond what is usually done with text files.

One consequence of the use of proprietary user interfaces is thatdebuggers have not taken advantage of the standard graphical userinterfaces that have lately evolved. In particular, they have not beenadapted to work with Web browsers, and that in turn means not only thatthe programmer must use a less-convenient user interface than thatprovided by the his or her Web browser, but also that a programmer whowants to debug a program that is running on a remote machine cannot usethe Web browser and the Internet to do the debugging, but must insteadhave a special connection to the remote machine which permits theprogrammer to use the proprietary interface.

What is needed, then, is a debugger which may be easily adapted to anumber of different kinds of user interfaces, including the userinterface provided by Web browsers and that works as well to analyzeinformation about past executions of a program as it does to analyzeinformation about a current execution. It is an object of the presentinvention to provide such a debugger.

SUMMARY OF THE INVENTION

The problems indicated above and others as well are solved by providinga debugging system in which a source of debugging information from anexecuting program performs update queries to a debug data base systemcontaining debugging information the source receives as a result of theexecution of the program and an interactive interface responds to userinputs by performing a read query on the debug data base which reads thedebug information placed there by the source and then formatting theresults of the read query as required by the user.

The information in the data base is persistent, and consequently, theinteractive interface can be used not only with debug information from acurrent execution of the program but also with debug information frompast executions of the program. Moreover, the debug data baseeffectively isolates the debugging information source and theinteractive interface from each other; consequently, changes in eitherwhich do not affect what is written to or read from the data base do notaffect the other. Further, a variety of different interactive interfacesmay read from the debug data base and a variety of different debuginformation sources may write to the debug data base.

Among interactive interfaces that may be used with the debug data baseis one that is adapted to be used with a standard World Wide Webbrowser. Such a Web server interactive interface has a URI (universalresource indicator) and responds to a message containing its URI byformatting and sending a HTML page to the browser. In many cases, theresponse also involves performing a read query on the debug database andreturning an HTML page that contains the results of the query. Since theWeb server interactive interface works with any Web browser, regardlessof the browser's location in the Internet, debugging may be done equallyeasily either on the system where the Web server interactive interfaceis located or on a remote system.

One species of debugging systems of the type described above employs asource of debugging information which provides memory debugginginformation such as memory allocations, memory leaks, and current heapsize.

Other objects and advantages will be apparent to those skilled in thearts to which the invention pertains upon perusal of the followingDetailed Description and drawing, wherein:

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is an overview of a debugging system which employs the invention;

FIG. 2 is a block diagram of a presently-preferred embodiment of theinvention;

FIG. 3 provides an overview of the debugger database of the preferredembodiment;

FIG. 4 shows a display generated from the HTML page by means of whichthe user selects a debugging report;

FIG. 5 shows a display generated from the HTML page by means of whichthe user views leak information;

FIG. 6 shows a display generated from the HTML page by means of whichthe user views heap allocation;

FIG. 7 shows a display generated from the HTML page by means of whichthe user views heap statistics;

FIG. 8 shows the display used to update debugger settings in a preferredembodiment;

FIG. 9 shows how buckets for objects are organized;

FIG. 10 shows free list defragmentation and footprint reduction; and

FIG. 11 shows how object buckets are organized in a preferredembodiment.

Reference numbers in the drawing have three or more digits: the tworight-hand digits are reference numbers in the drawing indicated by theremaining digits. Thus, an item with the reference number 203 firstappears as item 203 in FIG. 2.

DETAILED DESCRIPTION

The following Detailed Description will first present an overview of adebugging system that includes the invention, will then show how theinvention may be used to provide multiple user interfaces, including aWeb browser user interface, for an existing debugging system, and willthen present details of the debug database and the Web browser interfacein a preferred embodiment. The source of the debugging information in apreferred embodiment is an automatic memory management system, and theDetailed Description also includes details of the automatic memorymanagement system.

Overview of a Debugging System Constructed According to the Invention:FIG. 1

FIG. 1 is a conceptual block diagram of a debugging system 101 that isconstructed according to the invention. The major components ofdebugging system 101 are debugging data base system 107, debugger client102, and one or more user interface (UI) clients 111. Debugging database system 107 contains a database 110 with persistent debugginginformation 109(a . . . n) for a variety of executions of programs. Theterm persistent is used herein to mean that the debugging informationremains available in the database after execution of the program hasceased. Database 110 is managed by debug database server 106, whichresponds to queries from the other components of debugging system 101 bywriting to or reading from debug info 109 as required by the query(arrow 108). Conceptually, debug data base server 106 has two sets ofclients: debugger client 102, which provides update queries 105containing debug information 109 to database 110, and one or more userinterface clients 111, which provide queries that read selected debuginformation 109 from data base 110. Debug data base system 107 may bespecially implemented for system 101, or it may be one of the manycommercial data base systems.

One of the functions of debug database server 106 is to coordinate readsand writes of database 110. In some debugger systems 101, it will beenough simply to ensure that a read query never attempts to read datawhich is not yet available in database 110; in others, it may benecessary to ensure that what is read is the last complete write done bydebugger client 102. One method of coordinating reads and writes is totreat each read and write as a transaction and to use standard databasetransaction processing techniques; where consistency requirements areless stringent, the overhead of transaction processing can be avoidedand sufficient coordination of reads and writes may be achieved byordering the writes such that information which a given record in thedata base depends on is written to the database before the record itselfis written, thereby ensuring that all the information needed to respondto a query for which the given record is a result is in the database bythe time the record itself can be queried.

Debugger client 102 is a debugger which is executing a program beingdebugged 104 in debugger process 103. For purposes of the presentdiscussion, a debugger client 102 may be any entity which executes acomputer program in such a fashion that information about the executionwhich would not normally be available to a user of the program becomesavailable. Thus, debugger client 102 may be implemented expressly forsystem 101 or it may be any kind of existing interactive debugger.Debugger client 102 may have access to both the source code 117 andobject code 119 for program 104. Debugger client 102 may interpretsource code 117, but more generally, it will execute object code 119 anduse source code 117 to make debug info 109 more understandable to theuser of the debugger. Debug info 109 obtained from source code 117 andby means of execution of object code 119 is written to debug database110 by means of update queries to debug database server 106. In someembodiments there may be more than one debugger client 102; for example,a programmer may want to watch the behavior of two closely-cooperatingprograms, or there may be debugger clients specialized for differentprogramming languages or for different programming problems.

Each user interface client 111 receives inputs 125 from a user, respondsto some inputs by making a read query (Rquery) 113 for debug data baseserver 106, and responds to the results of Rquery 113 by formatting theresults and providing the formatted results to the user as formattedoutput 127. The forms of the inputs received and the outputs provided bya given interface client 111 depends on the kind of interactiveinterface employed by the user. Again, the interactive interface may beany presently existing or future interactive interface.

Debugger client 101 and the user interface clients 111 furthercommunicate with each other by means of control channel 121, which maybe any arrangement which permits transfer of messages between debuggerclient 102 and a user interface client 111. User interface client 111uses control channel 121 to transfer debugger commands to debuggerclient 101, while debugger client 102 uses control channel 121 totransfer debugger event messages to user interface client 111. Forexample, a first debugger command may instruct the debugger concerningthe kinds of information it is to output, while another may instruct thedebugger to stop execution of program 104 at a predetermined point. Adebugger event may inform interface client 111 that the predeterminedpoint has been reached and that the debugger has stopped execution ofthe program. Possible implementations of control channel 121 includeamong others inter-process communications, events and callbacks, sharedmemory, and a shared database.

Operation of debugger system 101 is as follows: as debugger client 102is executing program 104, it outputs debugger information 109 to debugdatabase server 106 by means of update queries 105. While doing this,debugger client 102 also responds to commands received on controlchannel 120 and where required, sends event messages via control channel120 to user interface client 111. Debug data base server 106 updatesdebug info 109 for the execution of program 104 being performed bydebugger client 102 in response to the update queries 105. While this isgoing on, user interface client 111 is responding to event messages fromdebugger client 102 and responding to user inputs 125. In both cases,the response may involve a command to debugger client 102 and/or a readquery 113 to debug database server 106. Debug database server 106responds to read query 113 by sending a result to user interface client111, which then formats the result as required by the interactive userinterface being used by the user and sends the formatted result to theuser. The user may respond to the formatted result with another input125, beginning the process again. Coordination between database server106 and client 111 may be done in many ways. In some cases, client 111may initiate all actions; in others, client 111 may respond to changesin database 110. In those cases, client 111 may simply repeatedly polldatabase 110 until a change occurs or data base system 107 may include amechanism for sending an event message to user interface client 111indicating that a change has taken place.

It is a particular advantage of debugging system 101 that debug databasesystem 107 isolates debugger client 102 and UI clients 111 from eachother. The builders of debugger client 102 need know nothing about theforms taken by user input 125 and formatted output 127 in a given userinterface client 111(i); all they need to know is the query interface todebug data base system 107. Similarly, the builders of user interfaceclient 111(i) need know nothing about the form taken by debuggerinformation in debugger client 102; they too, need to know only thequery interface to debug data base system 107. Moreover, becausedebugger client 102 and user interface clients 111 are isolated fromeach other, modifying a user interface client 111(i) or adding a newuser interface client 111(x) to debugging system 101 requires no changeswhatever to debugger client 102. Similarly, modifications of debuggerclient 102 or additions of new debugger clients requires changes to theuser interface clients 111 only to the extent that the changes indebugger client 102 involve the addition of new kinds of information todatabase system 107. If control channel 120 is implemented in debug database system 107, there is no direct communication between debuggerclient 102 and a UI client 111(i) and the isolation is complete.

A Memory Debugging System Incorporating the Invention: FIG. 2

In a preferred embodiment of the invention, the techniques describedabove are used to provide a Web browser user interface and a CLI userinterface for a memory debugger. A memory debugger is a debugger whichis used to analyze how the program explicitly allocates and freesmemory. Memory explicitly allocated by a program resides on theprogram's heap. One problem detected by a memory debugger is memory“leaks”, which occur when a program contains code that allocates memory,but does not contain code that frees the allocated memory when it is nolonger being used by the program. Leaks of course always waste memory;with serious leaks, all of the heap memory available to the program maybe occupied by leaks, and in that case, the program will fail when a newallocation is attempted. Another problem detected by a memory debuggeris data structures that continue to grow until they occupy all of theavailable heap memory.

The memory debugger in the preferred embodiment is the Great Circle™automatic memory management system, manufactured by Geodesic Systems,Inc. The main function of the Great Circle system is to provideautomatic memory management for programs written in languages such as Cor C++, which have no provision for automatic memory management. GreatCircle does automatic memory management by periodically collectinggarbage, that is, memory which was once allocated but is no longer beingused by the program, and freeing the garbage memory for reuse. From thepoint of view of memory debugging, of course, garbage is the result ofleaks. Thus, the information required to do garbage collection can alsobe used for memory debugging, and consequently, the Great Circle systemhas a debugging mode as well as a memory management mode. The GreatCircle system prior to its modification as required for it to be acomponent of a debugging system of the type shown in FIG. 1 is describedin detail in the manual, Great Circle Automatic Memory Management Systemfor C and C++, version 1.0, Geodesic Systems, Inc., 1995, which ishereby incorporated by reference into this Detailed Description.

FIG. 2 shows a presently-preferred embodiment of the invention in whichdebugger client 203 is implemented by means of Great Circle process 205which is executing a program 208 whose object code 200 has been linkedat the beginning of execution to a set of dynamically-linked libraries(DLLs) 211 which include code that performs Great Circle's memorymanagement and debugging functions. Of particular interest in thepresent discussion is the code in the DLLs for program initialization213, for memory allocation 215, and for garbage collection 217. When theGreat Circle system is operating in debugging mode, code 213, 215, and217 responds to debugger commands and makes update queries containingdebugger information to shared database system 226.

Shared data base system 226 implements the debug data base system andcontrol channel 120 in the preferred embodiment. As before, thecomponents of shared data base system 226 are a debug data base server225 and a data base 229. In the preferred embodiment, shared data basesystem 226 is implemented in memory that is shared between Great Circleprocess 205 and a user interface process 224 that implements UI clients111. Debug data base server 225 is a set of database management routinesin the shared memory that may be directly executed by either GreatCircle process 205 or user interface process 224. Database 229 in thepreferred embodiment consists of files which have been memory mappedinto the shared memory.

The preferred embodiment has two user interface clients: one, web serverclient 243 responds to inputs from and produces outputs to a Web browser249 which communicates with web server client 243 by means of Internet259. Use of Internet 259 means that Web browser 249 may be operating onthe computer system upon which Web server client 243 is executing or onany other computer system that has access via Internet 259 to thecomputer system upon which server client 243 is executing. The otheruser interface client is CLI client 251, which offers a standard CLIinterface to system 201. Inputs 253 are received from the device stdin,usually the keyboard, and outputs 255 go to the device stdout, usuallythe display. In the preferred embodiment, both Web server client 243 andCLI client 251 are implemented by means of code that is executed in userinterface process 224, and thus both have access to shared databasesystem 226.

Data base 229 contains three broad classes of information:

-   -   control information 231;    -   per-program information 233; and    -   per-execution information 235.        Control information 231 is the portion of the database that        implements control channel 120. As shown by dashed lines COMU        235 and COMR 221, either Web server client 243 or CLI client 251        provide commands to debugger client 203 by performing update        queries to control information 231; debugger client 203 receives        the commands by performing read queries on control information.        In the preferred embodiment, debugger client 203 executes code        in ALLOC 215 that performs a COMR query 221 on control        information 231 prior to allocating new storage for the        execution of program 208 Similarly, when an event occurs which        is of interest to a user interface client, debugger client 203        does an update query EVU 219 to control information 231. In the        preferred embodiment, the user interface client repeatedly does        event read queries 237 on control info 231 to determine whether        the event has occurred.

Per-program information 231 is information which is peculiar to a givenprogram that has been executed by the debugger but which is the same forall executions of the program. Debugger client 203 performs updatequeries 223 that write per-program information 231 for a given programwhen it initializes itself for the first execution of the program. Theupdate queries are done by code in INIT 213. Per-execution information235 is information that is accumulated on each execution of a program bydebugger client 203. The update queries that provide per-executioninformation 235 to data base 229 are done by code in ALLOC 215 that isexecuted whenever memory is allocated during execution of a program andcode in COLLECT 217 that is executed whenever a garbage collection isdone during execution of a program. Per-program info 233 andper-execution info 235 are read by read queries (RQUERY) 239 made by theuser interface client that needs the information.

Details of Database 229: FIG. 3

FIG. 3 shows details of the contents of database 229 in the preferredembodiment of FIG. 2. As already mentioned, database 229 is implementedas a set of database files 301 which has been mapped into address space303 for Great Circle process 205 and address space 305 for process 224which executes the user interface clients in the preferred embodiment.There are three kinds of information in control information 231: a queueof commands 307 for debugger client 203, a queue of events 309 for theuser interface process, and debugger settings 311, which are currentcontrol and status settings for debugger client 203. The controlsettings are set by the user interface clients and read by debuggerclient 203 and the status settings are set by debugger client 203 andread by the user interface clients.

In the preferred embodiment, debugger client 203 responds to thefollowing commands:

-   -   collect: perform garbage collection for the program 208 being        currently executed by debugger client 203;    -   stop: stop execution of the program 208 being currently executed        by debugger client 203;    -   restart: restart execution of the program 208 being currently        executed by debugger client 203.        Of these, the first is used by both web server client 243 and        CLI client 251, but the second and third are used only by CLI        client 251. In the preferred embodiment, only CLI client 251        responds to a debugger event. The event is the detection of a        memory leak. When the event occurs, CLI client 251 responds by        querying database system 226 and to obtain the information about        the leak that was written there by debugger client 203. The        control and status settings 311 will be explained in more detail        in the following description of the user interface for web        browser 249.

Per-program information 233 in the preferred embodiment is a symboltable for each program that debugger client 203 has executed. Debuggerclient 203 makes the symbol table and writes it to database 229 as partof the initialization it performs when it executes a program for whichthere is no symbol table in database 220. The symbol table contains theinformation which is required to relate information about the executionof a program 208 to names and locations in source code 207 for theprogram.

Per-execution information 235 in the preferred embodiment includesinformation concerning the execution of program 208 which debuggerclient 203 is currently performing and information from executions ofprograms which debugger client 203 has performed in the past. Theinformation for the current execution includes current heap statistics315, which shows the space currently occupied by storage in theprogram's heap, and execution information 317 for the current execution.Execution information 317 includes allocation statistics 319, indicatinghow much memory has been allocated, garbage collection statistics 321,indicating the memory leaks, and stack trace 323, showing the calls andreturns made by the program during the program execution. For thecurrent execution, execution information 317 shows the state of theprogram as of the most recent memory allocations and garbagecollections. For past executions, execution information 317(i,j) forexecution j of program i shows the state of execution(j) as of theconclusion of execution. Thus, allocation statistics 319 will show allmemory allocated, collection statistics 321 will show all leaked memory,and stack trace 323 will show the stack trace for the entireexecution(j).

Operation of Debugging System 201

When debugger client 203 is not executing a program 208, a userinterface client can still access execution information 317 (i,j) forany program(i) and execution (j) for which the information is present indata base 229. To access the information, the user interface clientfirst queries database system 226 to obtain a list of the programs andexecutions, which it displays to the user, and then responds to a userselection of a program and execution by displaying execution information317 (i,j) together with information from the relevant symbol table 313.What information is displayed is determined from further user inputs.

To analyze an execution of a program that is presently taking place withdebugging system 201, the user first begins an execution of the programin which the Great Circle DLLs 211 have been linked to the program. Theprograms in the DLLs 211 cause debugger client 203 to check controlinformation 231 for commands and settings each time it allocates memory,to write the current program pointer to stack trace 323, and to writestatistics concerning the allocation to allocation statistics 319. Eachtime debugger client 203 does garbage collection, it writes collectionstatistics to collection statistics 321. For each detected leak, thestatistics for the leak show the size of the leak and the point in thestack trace at which the leak occurred. If the user of an interfaceclient selects the current execution(m) of program(l), the resultingquery to database system 226 selects and returns the informationcurrently in execution info 317(l,m). In a preferred embodiment, thequery to execution info 317(l,m) is repeated each time the user of aninterface client desires a different view of the information inexecution info 317(l,m). Furthermore, the user can explicitly requestthe interface client to perform a new query to obtain the current stateof execution info 317(l,m). In other embodiments, the debug database mayprovide an event message to the interface client when execution info317(l,m) changes and the interface client may respond thereto by makinga new query.

As indicated above, debugger client 203 further responds to collect,stop, and restart commands from the interface client. Ordinarily,debugger client 203 does garbage collection at predetermined intervals;execution info 317(l,m) reflects the most recent garbage collection.When the user interface client issues a collect command, debugger client203 responds by making the collection the next time it does a memoryallocation operation and outputting the new collection statistics tocollection statistics 321. In a preferred embodiment, the user waitsuntil he or she believes that a memory allocation operation has takenplace and makes a new query to obtain the current state of executioninfo (l,m). The results of the new query reflect the garbage collection.In other embodiments, garbage collection may be done by a backgroundthread that runs in response to the command and the update querycontaining the collection statistics may cause an event to be generatedto the user interface client, which would then respond by making a newquery. The stop command simply stops execution of program 208(l); therestart command restarts the execution of program 208(l).

Coordination between UI process 224's updates to and reads from databasesystem 226 and Great Circle process 205's updates to and reads fromdatabase system 226 need not satisfy the strict requirements oftransaction processing, since even results that are not quite currentare useful and the user may easily update the results he or she has.That being the case, debugging system 201 avoids the overhead oftransaction processing by ordering the writes in such a fashion that allof the information required for a read query is available by the timethe read query can be made. For example, the information about a memoryleak that is output to the user includes the stack trace for the leak;in performing update queries on data base system 226, debugger client102 performs the update query that writes the stack trace before itperforms the update query that writes the leak information;consequently, if a read query can return leak information for a leak, itcan also always return the stack trace for the leak. In otherembodiments, of course, other coordination techniques, includingtransaction processing, may be used.

Details of Web Server Client 243: FIGS. 4-8

Web server client 243 receives inputs from and provides outputs to anystandard Web browser 249. The inputs and outputs are transferred viaInternet 259. From the point of view of Web browser 249, Web serverclient 243 is a standard Web server, that is, it receives a universalresource locator (URL) which specifies the server and in many casesattached data and responds to the URL by providing a page in HTML formatto web browser 249. The attached data is used at the location specifiedby the URL. If the specified location has access to a data base, thespecified location may use the attached data to form a query to the database and return the result of the query in the HTML page. Details aboutall of this may be found for example in A Beginner's Guide to HTML,published by NCSA and available at pubs@ncsa.uiuc.edu and in the section“Common Gateway Interface(CGI)” of HTML for Dummies, available inOctober, 1998 at www.lanw.com/html4dum/h4d3e/extras/ch18sec1.htm.

The URL specifies a Web server by means of a port number in the systemon which the Web server is running and an Internet Protocol (IP) addressfor the system in the Internet. The URL for web server client 243specifies port number 50565. The IP address for the system in the URLdepends on whether Web browser 249 is running on the same system as Webserver client 243. If it is, the IP address is the IP loop-back address,normally 127.0.0.1, so that messages from Web browser 249 to client 243go directly to client 243, without passing outside the system to whichbrowser 249 and client 243 belong. If IP browser 249 is not running onthe same system, the IP address of Web server client 243 is the IPaddress of the system on which it is running and the messages passbetween browser 249 and client 243 via Internet 259 external to thesystems upon which browser 249 and client 243 are located.

Detailed Interaction Between Browser 249 and Server 243: FIGS. 4-8

The interaction between Web browser 249 and Web server client 243 in apreferred embodiment is as follows: The user begins the interaction byspecifying the URL of Web server client 243 to Web browser 249 thensends the URL. When server 243 receives the URL, it sends an HTML pagewhich, when displayed by browser 249, has the appearance shown in FIG.4. Page 401 is the select program page, so called because it permits theuser of browser 249 to select which execution of a program he wants toview a debugging report for. The execution is selected by clicking onthe program's pathname in execution listing 413. Execution listing 413also shows the time the debugging information for the program wasrecorded at 417, the amount of leaked memory at 419, and a file 421which contains the debugging report for the execution. This file is oneof the ones that is mapped into memory to provide debug data base 229.

Once a program has been selected, its name and the number of leakedbytes recovered are indicated at 423 in page 401. Box 407 indicates thedirectory in which debugging reports may currently be found. The usercan change the directory, and future debugging reports will be saved inthe indicated directory. Box 409 indicates how many reports for theprogram will be saved; the user can of course change that value as well.If the selected program is currently being executed by debugger client203, the user can click on update display button 411. In responsethereto, web browser 249 sends a form together with Web server client243's URL. The form indicates the program's pathname and the currentsettings in fields 407 and 409, and Web server client 243 responds tothe form by performing a query on the information for the currentexecution of the program in shared database system 226 and making a newselect page 401 in which execution listing 413 is updated to reflect themost recent updates of database 229 by debugger client 203. Further, thedirectory for the debugging reports and the number of reports saved willbe changed as indicated in boxes 407 and 409.

Once the user has selected a program execution, the user may selectother HTML pages to obtain more detailed information about thatexecution. An HTML page is selected by selecting one of the tabs 403.Each time the user selects a tab, web browser 249 responds by sendingthe URL of client 243 together with a form which contains an indicationof the tab that has been selected, the pathname of the program, and anindication of which execution listing was selected. Web server client243 responds to the information in the form by performing a query ondata base 229 which obtains the information for the selected programthat is required to make the selected HTML page and returning the pagewith the information to browser 249. If the selected execution is acurrent execution, the selection of a new HTML page will cause a newquery of database 229 for information about the current execution, andconsequently, selection of a new HTML page has the same effect asclicking on Update Display button 411.

FIG. 5 shows leak information page 501. This page shows detailed leakinformation for the program execution selected by the user from selectpage 401. The page has the same general format as page 401; informationspecific to the page is contained in area 502. Area 502 has two mainparts: control panel 504 and leak information display 525. The settingsof control panel 504 determine what information appears in leakinformation display 525. Control panel 504 contains update displaybutton 411 and a collect now button 503. When the user clicks on collectnow button 503, the form transmitted with the URL to web server client243 indicates that client 243 is to send a collect command to debuggerclient 203, so that debugger client 203 will perform a garbagecollection in the near future. The control panel further contains field507, which permits the user to filter the leak information, field 509,which specifies a sort mode, and an indication of how much of theinformation is to be displayed. When the user clicks on update displaybutton 411, this information is included in the form which is sent toWeb server client 243 and Web server client 243 uses the information toformulate its query on database 229 and construct the new leakinformation page 501.

Leak information display 525 contains a leak listing 527 for each leak.The listings 527 are ordered by leak size. Each listing 527 containsleak statistics 513 and a leak stack trace 529. Leak statistics 513specify the amount allocated and the amount leaked in terms of bothbytes and objects. Leak stack trace 529 indicates the execution paththat resulted in the leak. The execution path has columns for programcounters (523), line numbers (521), file names (519), function names(517), and module names (515). It thus relates the leak to programcounter positions in modules and relates the program counter positionsto the functions the program counters are in, the files that contain thesource code for the functions, and the line number in the source codecorresponding to the program counter position. The information forcolumns 515, 519, and 521 is of course obtained from symbol table 313for the program.

FIG. 6 shows allocation profiler page 601. This HTML page showsallocations of memory on the heap during execution of the program. Thepage has in general the same form as page 501, with the changes thatcorrespond to its function. Thus, the sort 603 is now by live memory,area 605 displays live and allocated memory in terms of bytes andobjects, and stack trace 529 gives the execution paths for theallocation events. The queries that produce the information on form 601of course are directed to allocation information rather than leakinformation.

FIG. 7 shows heap statistics page 701. This page contains validinformation only when debugger client 203 is currently executing aprogram. Page 701 displays a running total of leaked memory recovered byGreat Circle and of memory that has been unmapped by explicit user callsto free ( ) or delete made by the program. It also breaks down the totalcurrent heap, which is memory actually still in use, into severalcategories:

-   -   Live memory, shown at 703, includes all data structures that are        currently being used (or at least explicitly pointed to) by        program 208.    -   Debug info, shown at 709, is the memory that Great Circle itself        requires to keep track of stack traces and other information        about the objects allocated by program 208.    -   Free lists, shown at 711, are structures that Great Circle, like        any memory allocation function, stockpiles in order to perform        future allocations rapidly and efficiently, without inducing        excessive memory fragmentation.    -   Waste, shown at 713, unlike free lists, is memory that is        temporarily unavailable for future allocations because of        fragmentation.

The sum of these categories is the current heap size, shown at 717. Thecurrent heap size is the actual current footprint in memory of program208 that debugger client 203 is currently executing. Since Great Circleattempts to reduce the footprint whenever it can, Heap Statistics page701 also shows the maximum heap at 719. The maximum heap is thehigh-water mark of heap usage over the life of program 208.

Other HTML Pages Produced by Web Server Client 243

Other HTML pages which the user may select include a settings page,which permits the user to set and read a number of parameters thatcontrol the operation of debugger client 205, a log file page whichpermits the user to view an ASCII log file produced by debugger client203, a page whose selection causes a URL to be sent to Geodesic Systems'Web site, and a page whose selection causes a page in the help systemfor the debugging system to be displayed. HTML pages 501 and 501 alsoinclude help buttons for help that is particularly relevant to thosepages. In the following, the settings page and the log file page will bediscussed in greater detail.

FIG. 8 shows the buttons 801 of the settings page. Each button shows thecurrent setting of the parameter specified by the button, and in thecase of the writeable parameters indicated at 805, 807, 809, 811, 813,821, 823, 825, and 827, debugger client 203 responds to the newparameter value in real time when the user changes the parameter andthen clicks on update settings button 803. Clicking on button 803 causesweb browser 249 to send a form to Web server client 243 that containsthe new parameter settings and Web server client 243 responds to theform by making an update query with the settings that updates therelevant parameters in debugger settings 311. As previously mentioned,debugger client 102 queries database 226 to obtain the current values ofsettings 311 as part of each allocate operation, and on reading thesettings, it updates its parameter values and begins to operateaccording to the updated parameters. Changes made via the settings pageaffect only the program execution during which they are set. Defaultvalues for the settings may be supplied when debugger client 203 isconfigured. The log file page displays the log file, gc.log, that wasgenerated by Great Circle for this program run. This file, unlike thefiles that make up database 229, is in a plain ASCII format that is wellsuited for piping through custom scripts provided by the user ofdebugger system 201.

As can be seen from FIGS. 4-8, the HTML pages produced by Web serverclient 243 in response to inputs from Web browser 249 provide a userinterface to debugger client which is clear and easy to use and can beemployed on any system which has a standard Web browser and a connectionto Internet 259. The interface further permits the user to view theresults of past executions of programs by debugger client 203 and toview the results of a current execution as it happens. While viewingresults being produced by a current execution, the user may send acollect command and/or new parameter settings to debugger client 203,and debugger client 203 will respond in real time to the collect commandand parameter settings.

Improved Memory Allocation and Footprint Management Techniques

As mentioned above, the memory debugger of the preferred embodiment is amode of operation of the Great Circle memory management system. In thefollowing, two improvements in memory allocation and program footprintmanagement that are employed in the version of the Great Circle memorymanagement system which is used in the preferred embodiment of thedebugging system are described in detail.

Introduction

The two techniques described in the following are used the preferredembodiment to reduce fragmentation which results from the fact that theGreat Circle memory management system uses a non-moving garbagecollector, that is, a garbage collector that cannot eliminatefragmentation by moving live data, leaving all free space in consecutivelocations. For details about non-moving and moving garbage collectors,see Jacques Cohen and Alexandru Nicolau, “Comparison of compactingalgorithms for garbage collection”. ACM Transactions on ProgrammingLanguages and Systems, 5(4):532-553, October 1983. The first techniqueis intended to reduce internal fragmentation in allocators that use aBiBoP scheme (Big-Bag-of-Pages) In a BiBoP allocator, the allocatorallocates objects that are smaller than a memory page from a free listin which the objects are takes from page-size containers. All of theobjects allocated from a given free list have the same size. Thus, whenthe allocator is given the size of the object it is to allocate, itallocates from the free list into whose objects the object to beallocated fits most closely. For details, see Hans-Juergen Boehm andMark Wieser. “Garbage collection in an uncooperative environment”,Software Practice and Experience, 18(9):807-820, September 1988. Thesecond technique is intended to reduce external fragmentation and usesvirtual memory primitives that can be found in most modern operatingsystems.

Allocators such as the one described in the Boehm paper cited above havea number of free lists for allocating objects of a size such that morethan one will fit onto a memory page and a single free list forallocating objects that are larger than that. Objects of a size suchthat more than one will fit onto a memory page are termed small objects,and those that are larger than that are termed large objects. With allof the small object free lists, the container size is 1 page. In thispaper, we show that when the allocator is able to allocate only fromsmall object free lists and a large object free list, allocation ofsmall objects with sizes such that a number of them do not fit compactlyinto a single-page container or of large objects with sizes that do notfit compactly into an integer number of pages results in a largeinternal fragmentation in the free lists. To solve this problem, thefirst technique introduces free lists for allocating objects that do notfit compactly into a single-page container but that do fit compactlyinto a container made of a number of consecutive pages. The objects onthese free lists are termed herein medium objects. As with smallobjects, there are a number of free lists for medium objects, with themedium objects on a given free list all having the same size, and theallocator takes a medium object from the free list into whose objectsthe object being allocated fits most closely.

Most modern operating systems have separate virtual memory operationsfor reserving virtual address space and committing swap space to thereserved virtual address space. Because this is the case, swap space maybe committed and uncommitted at runtime. The basic idea of the secondtechnique is to uncommit swap space belonging to logical pages in thosesections of the large object free list that are too fragmented to beused for most large object allocations, and to commit that swap space tological pages located at consecutive locations in the address space. Ineffect, this technique provides many of the defragmentation benefits ofmoving garbage collection by virtually moving the free data rather thanthe live data. In addition, this technique allows returning to theoperating systems parts of the heap that were used during periods ofheavy allocation and that are no longer used. We will refer to thisaspect of the technique as footprint reduction.

The ideas presented here are explained in the context of garbagecollection. Incremental garbage collectors which use these ideas musthave a decommit barrier which ensures that the garbage collector doesnot reference a logical page that has been decommitted. A garbagecollector with a decommit barrier is described in detail in U.S. patentapplication Ser. No. 08/891,687, M. Spertus, et al., Incremental garbagecollector with decommit barrier, filed Jul. 11, 1997, which is herebyincorporated by reference into the present patent application. The ideascan, however, also be applied to any general-purpose memory allocator,regardless of whether it uses garbage collection. In the following, apreferred embodiment of these techniques which is employed in the GreatCircle memory management system is explained in detail, beginning withmedium objects.

Medium Objects: FIG. 9

Medium objects reduce fragmentation by providing a better fit betweenthe objects being allocated and the container which holds them. InBoehm's allocator, the container size for all objects which are smallerthan or equal to a page is a page; for all objects which are larger thana page, the container is the minimum number of pages required to containthe object. An important drawback of this approach is that the internalfragmentation with small objects that do not fit well into a single pageor large objects that do not fit well into a multiple of pages can bevery large. For example, if a small object is a little larger than halfa page size, almost half of the page which contains it will be wasted,and if a large object is a little larger than a page, almost the entiresecond page will be wasted. Since we found that these allocation sizeshappen to be the common case for many applications, we decided to addfree lists with medium objects, that is, free lists whose containers aresome number of consecutive pages, with the number of consecutive pagesfor a given free list being chosen such that objects of the sizecontained in the free list fit compactly into the container.

The benefits of medium objects can be seen from the following example:let us assume that there is a request to allocate an object of 2050bytes in a system that has a page size of 4096. In an allocator thatallocates only from free lists of small and large objects, an object ofsuch a size is a small object, but only one such small object will fitin a single page, and consequently, the allocator will return an objectof 4096 bytes because the page cannot be subdivided into any smallerequal-size portions that will contain the object to be allocated. Anallocator that uses medium objects can divide a container made up of twoconsecutive pages into 3 objects of size 2730 bytes (plus 2 spare bytesthat cannot be divided), and return one of these objects. In the firstcase, 2046 bytes are wasted, and in the second case only 680 bytes arewasted.

To put the above more formally, the internal fragmentation is thepercentage of wasted space for a given object size. It can be computedby subtracting the requested object size from the real size of theobject returned by the allocator and dividing the result by the realsize.% Fragmentation=100.0*(realSize−requestedSize)/realSize

As one would expect from the foregoing, in an allocator without mediumobjects, the fragmentation for objects with sizes around the size of thepage approaches 50%. Especially at sizes 2049 and 4097 bytes (one byteafter half the page size and one byte after the page size) thefragmentation reaches 50%. With medium objects however, the internalfragmentation for these sizes may be bounded to lower levels, with thebounds depending on the fit between the sizes of small and mediumobjects and their containers. The memory allocator of Great Circleallocates objects out of three kinds of containers: small objects areallocated out of single-page containers. Medium objects are allocatedout of containers that are made of consecutive pages. Large objects areobjects for which more than one page is allocated. The small and mediumobject allocators have a separate bucket for each of the sizes ofobjects that they allocate. Each of the buckets is what is termed asegregated free list. See Paul R. Wilson, Mark S. Johnstone. MichaelNeely, and David Boles, Dynamic Storage Allocation: A survey andCritical Review, available for anonymous FTP from cs.utexas.edu inpub/garbage/ in October, 1998.

FIG. 9 shows the structure of a bucket 901. Each bucket 901 is made upof a page information structure 907 which includes information 904indicating the size of the objects that will be allocated from thebucket and a free list pointer 906 indicating the head of the list ofunallocated objects 911 contained in bucket 901. The objects 911 arestored in one or more containers 917, which are m ade up of one or morecontiguous logical pages 905. The size of the container is the number oflogical pages 905 which reduces waste 910 to a minimum for the size ofobject 911 stored in the bucket. Each object 911(i) which has not yetbeen allocated has an object free list pointer 913 pointing to the nextunallocated object 911. When an object is allocated, the free listpointer 913 is overwritten by data and free list pointer 906 is set topoint to the next unallocated object 911 in the list. When an object isfreed, the allocator to which the bucket belongs links the freed objectin at the head of the free list. This has the advantage that an objectthat has been used tends to be reused before it is removed from thecaches in the machine that the program that uses the object is executingon. When a bucket 901 runs out of unallocated objects 911, the allocatorthat uses the bucket obtains an additional container 917 for the bucketfrom the large object allocator.

FIG. 11 shows small object buckets, medium object buckets, and largeobject free list as they may be employed in a memory allocation systemthat employs small and medium objects. There is a set of small objectbuckets 1107 for small objects 1104, that is objects that have sizessuch that they fit into a 1-page container 1105 with little waste. Eachsmall object bucket 1103 contains small objects of a single size.

There is further a set of medium object buckets 1113 for medium objects1112, that is, objects that have sizes such that they fit into amulti-page container 1111 with little waste. Again, each medium objectbucket 1109 contains medium objects of a single size, and the size ofmulti-page container 111 is chosen to minimize waste for the size ofmedium object in bucket 1109.

Large object free list 115, finally, can be seen as a free list in whicheach large object to be allocated has its own bucket that contains thenumber of pages required to allocate the large object. Large object freelist 115 is a list of free logical pages that is ordered by address.Ordering by address permits coalescing of objects that are returned tothe large object free list. The allocator satisfies a request for alarge object by returning the first block of pages in the free list thatis large enough to accommodate the large object. Access by the allocatorto the buckets and large object free list is speeded up bybytes-to-bucket table 1119, which maps the size of an object to beallocated in bytes to the bucket which contains the objects into whichthe object to be allocated fits most closely or to the free list if theobject is larger than the largest medium object.

A preferred embodiment sets up buckets 1107 and 1113 as required by thepage sizes and data granularities of the system that the allocator isallocating memory for. The algorithm first sets up small object bucketsfor single-word objects and objects containing 1 to 8 double words; thenthe algorithm sets up buckets for objects of increasing size up to 1page. For each size, the algorithm determines how much waste willresults if a small object bucket 1107 is made for the size, and if thewaste is above a threshold, the algorithm determines the size ofcontainer required for a medium object bucket for the 30 object and setsup the medium object bucket. It should be noted here that medium objectsneed not be less than a page in size. For example, if objects of a sizeof 1⅓ pages were common, it might be worthwhile to set up a mediumobject bucket that had a container size of four pages.

Free List Defragmentation and Footprint Reduction: FIG. 10

The second technique reduces fragmentation in free list 1115 of largeobjects. Notice that the small and medium object buckets 1107 and 1113are relatively unaffected by external fragmentation, because the freeelements in a small or medium object bucket are always large enough tosatisfy an allocation request where the object being allocated is takenfrom the bucket. In addition, the technique can also uncommit physicalmemory pages to which logical memory pages in the free list are mapped,allowing long-running programs to reduce their swap space requirementswhen their memory requirements decrease.

Free list defragmentation is based on the observation that movingcollectors make the free memory space contiguous by moving the livedata. However, the free memory space by definition contains no livedata; consequently, it can be made contiguous simply by committing thephysical pages corresponding to the free memory space to a differentportion of the virtual address space where the free memory space willhave contiguous virtual addresses. This provides a major defragmentationbenefit of moving collection without the complexity, restrictions, orexpense of moving data and updating pointers.

FIG. 10 shows how defragmentation works. On the left side, there is arepresentation 1005 of the heap in virtual memory and in physical memoryprior to footprint reduction. The heap is part of an arena 1006 which isa range of contiguous virtual addresses. Arena 1006 is subdivided intological pages 905, some of which have physical pages 1002 committed tothem in the swap space. Prior to defragmentation, seven logical pages905 have physical pages 1002 committed to them; four of the pages,indicated by L, contain live data; three of the pages, indicated by F,are free: three pages with free objects, and three pages, indicated bythe fact that they are blank, are uncommitted, i.e., do not have swapspace assigned. The three free logical pages 905 do not occupyconsecutive locations in the virtual address space, and therefore arequest to the allocator for a three-page object cannot be satisfiedwith the available free logical pages. Defragmentation de-commits thephysical pages 1002 from the three free non-consecutive logical pages905 to which they are committed in representation 1005, making themavailable to be committed to consecutive logical pages 905, as shown at1009 in representation 1007. The large object can thus be allocated fromthe pages at 1009 without increasing the swap space.

To implement defragmentation and footprint reduction, the pages of theheap are represented by an array of bytes called page-flags, where eachbyte represents a page. Every bit in a byte represents a differentcharacteristic of the page. For defragmentation and footprint reduction,only three bits in each byte are used: committed-bit, free-bit, andrecently used-bit. The array is shown at 1011. There is a page flagentry 1011 for each logical page 905 in arena 1006; the relevant flagsappear as committed bit 1015, free bit 1017, and recently-used bit 1019.Committed bit 1015 is used in the garbage collector's decommit barrier.Before the garbage collector references a logical page 905, it checkscommitted bit 1015 in the logical page's page flag entry and makes thereference only if the committed bit is set.

At initialization time, the allocator creates arena 1006 by mapping alarge sequence of logical pages 905. This mapping operation reserves thevirtual address space required for the logical pages, but does notcommit swap space to any of the pages. Since the arena has been mapped,no other memory map operation will return a page in this range. However,since no swap space is reserved, a memory read/write operation to a wordin this range of pages at this point in the execution of the program mayresult in a segmentation violation. Finally, all of the flags in thePFEs 1013 for logical pages 905 are cleared.

During a request for allocation of a large object, if the request cannotbe satisfied with the existing objects in the free list, the allocatorwill do the following. It will search in page-flags 1011 for a set offree logical pages 905 in arena 1006 which are at contiguous locationsin the virtual address space and which are together large enough tosatisfy the request or some larger amount if the requested size is toosmall. Then it will call a virtual memory operation to commit swap spacefor this range of pages. The swap space of course includes the earlierdecommitted physical pages 1002. The reason a larger amount is committedif the requested size is too small is to amortize the cost of thevirtual memory operation. This range of pages is returned to the freelist, the physical pages 1002 for the non-contiguous free logical pages905 are committed to the contiguous free logical pages 905, and thecorresponding committed-bits and free-bits in the PFEs 1013 for thelogical pages 905 involved in the operation are updated. Finally, theallocation request is satisfied. If the number of consecutiveuncommitted pages in arena 1006 is not enough, another large group ofuncommitted memory is mapped and added to arena 1006.

Footprint reduction is done using recently-used bits 1019. Whenever agroup of logical pages 905 is returned to the free-list, thecorresponding recently used-bits and the free-bits are set. The recentlyused-bits tell the allocator that the corresponding page has beenrecently used and that it is not a good candidate for footprintreduction. During a footprint reduction, the physical pages 1002corresponding to logical pages 905 whose recently-used bits 1019 arecleared are uncommitted from those logical pages 905, i.e., committedbits 1015 for the logical pages 905 are cleared and the swap spacerepresented by the physical pages 1002 is returned to the operatingsystem. When the execution of the program terminates, the recentlyused-bit is cleared for all of the logical pages 905 in its arena 1006.

The frequency with which footprint reduction is executed is linked tothe activity of the allocator. In our implementation, a footprintreduction is performed after a pre-specified number of garbagecollections. If a logical page 905 has remained on free list 901 duringthis pre-specified number of garbage collections, its physical page 1002is uncommitted and returned to the operating system. Programs thatexplicitly manage their memory will run a footprint reduction after apre-specified number of bytes have been explicitly returned to thefree-list. Alternatively Great Circle supplies a footprint reductionprocedure that the program can explicitly call after periods of heavyallocation.

Alternatives to the commit/uncommit operations are the map/unmapoperations. The difference is that the uncommit memory operations returnthe associated swap space to the operating system, however the addressspace range is kept. The unmap operation returns both the address spaceand the swap space to the operating system. We have decided to use thecommit/uncommit operations over a contiguous uncommitted arena becauseit allows recycling address space. The map operation can return memorymappings that are not contiguous, resulting in a heap whose virtualaddress space has holes.

Another modification for footprint reduction is that during theallocation of large objects every search in free list 1115 always startsfrom the first block in the list. This will result in reusing the samelarge objects most of the time and leaving the least used objects at theend of the list. If a new search started where the previous one ended itwould reuse all the objects in the list and would not give theopportunity for footprint reduction.

A good side effect of footprint reduction is that pages that areblack-listed, and therefore cannot be used because they are beingpointed by false pointers, are unmapped if they continue black-listedfor several consecutive allocations. For details on black-listed pages,see Hans-Juergen Boehm, “Space-efficient conservative garbagecollection”. In Proceedings of the 1993 SIGPLAN Conference onProgramming Language Design and Implementation, Albuquerque, N.Mex.,June 1993. ACM Press, pages 197-206.

Conclusion

The foregoing Detailed Description has disclosed to those skilled in thearts to which it pertains how to make and use debugging systems in whicha database system mediates between the debugger and the interface theuser employs to see the results of execution of a program by a debugger.The Detailed Description has provided a detailed disclosure of apreferred embodiment in which the debugger is a memory debugger and theinterfaces employed by the users include a CLI interface and a Webbrowser interface. It will, however, be immediately apparent to thoseskilled in the relevant arts that debugging systems of the typedescribed herein may be made using any type of interactive debugger andany type of user interface. Moreover, the database may be implementedusing a commercially-available database system, as well as one designedspecifically for the debugging system. The manner in which the debugger,the debugging system, and the user interface components interact will ofcourse depend on the requirements of the debugging system and thecapacities of the database system. The process architecture of thedebugging system may similarly vary between one extreme in which allcomponents execute in a single process and another extreme in which eachcomponent consists of one or more processes. The Detailed Descriptionhas further included details of the HTML pages used in a preferredembodiment; however, what is on an HTML page in a system that is builtaccording to the principles disclosed herein and that employs a Webbrowser as a user interface will depend on the nature of the debuggingbeing done and the taste of the designer of the HTML pages.

For all of the foregoing reasons, the Detailed Description is to beregarded as being in all respects exemplary and not restrictive, and thebreadth of the invention disclosed here in is to be determined not fromthe Detailed Description, but rather from the claims as interpreted withthe full breadth permitted by the patent laws.

1. An interactive debugging system for debugging an executing programcomprising: a debug data base system which stores debugging informationindicating an execution state of the program and responds to queries onthe debugging information; a debugging information source which islinked to the program at the beginning of execution thereof and whichprovides an update query containing the debugging information to thedebug data base system during execution of the program; and aninteractive interface that responds to an input from a user by providinga read query on the debugging information to the debug data base systemduring execution of the program and responds to results returned for theread query by formatting the results and outputting the formattedresults to the user.
 2. The debugging system set forth in claim 1wherein: the debugging information persists after the executing programhas ceased executing; and the interactive interface further responds tothe input from the user by providing a read query on the persistentdebugging information after the executing program has ceased executing.3. The debugging system set forth in claim 2 wherein: the persistentdebugging information includes persistent debugging information for aplurality of executions of the program; and the input selects persistentdebugging information from an execution of the plurality thereof.
 4. Thedebugging system set forth in claim 3 wherein: the input furtherspecifies one of a plurality of views of the debugging information; andthe interactive interface responds to the input by providing the readquery as required for the view specified in the input.
 5. The debuggingsystem set forth in claim 1 wherein: the input further specifies one ofa plurality of views of the debugging information; and the interactiveinterface responds to the input by providing the read query as requiredfor the view specified in the input.
 6. The interactive debugging systemset forth in claim 1 further comprising: a plurality of the interactiveinterfaces.
 7. The interactive debugging system set forth in claim 1further comprising: a plurality of the debugging information sources. 8.The interactive debugging system set forth in claim 1 wherein: theinteractive interface is associated with a universal resource indicator,receives a first message according to the http protocol which isdirected to the associated universal resource indicator, and responds tothe first message by sending a second message according to the httpprotocol, the first message containing the input from the user to theinteractive interface and the second message containing the formattedresults.
 9. The interactive debugging system set forth in claim 8wherein: the interactive interface is part of a given computer system;and the source of the first message and the destination of the secondmessage are in the alternative local to the given computer system orremote therefrom.
 10. The interactive debugging system set forth inclaim 1 further comprising: a channel for transferring a command fromthe interactive interface to the debugging information source duringexecution of the program, the interactive interface transferring thecommand in response to another input from the user and the debugginginformation source responding to the command by providing an updatequery to the debug data base system.
 11. The debugging system set forthin claim 10 wherein: there is a plurality of the commands; and thecommands further include a stop command for stopping the executingprogram and a restart command for restarting the executing program. 12.The debugging system set forth in claim 10 wherein: the debug data basesystem further stores command information and the channel transfers thecommand by means of an update query from the interactive interface tothe debug data base system and a read query to the debug data basesystem from the debugging information source.
 13. The interactivedebugging system set forth in claim 10 wherein: the channel furthertransfers an event indicator from the debugging information source tothe interactive interface, the interactive interface responding to theevent indicator by providing a new read query to the debug data basesystem.
 14. The interactive debugging system set forth in claim 13wherein: the debug data base system further stores event information andthe channel transfers the event information by means of an update queryfrom debugging information source to the debug data base system and aread query to the debug data base system from the interactive interface.15. A storage device for storing digital information, the storage devicebeing characterized in that: the storage device contains a programwhich, when executed in a computer system, implements the interactivedebugging system set forth in claim
 1. 16. An interactive debuggingsystem for debugging memory usage by an executing program, the debuggingsystem comprising: a debug data base system which stores debugginginformation indicating a current state of memory usage by the executingprogram and responds to queries on the debugging information; a memoryallocator used by the executing program to allocate memory, the memoryallocator providing an update query containing the debugging informationto the debug data base system; and an interactive interface thatresponds to an input from a user by providing a read query on thedebugging information to the debug data base system during execution ofthe program and responds to results returned for the read query byformatting the results and outputting the formatted results to the user.17. The debugging system set forth in claim 16 wherein: the memory usageinformation includes information from which the current heap size forthe executing program may be determined; and the read query obtains theinformation from which the current heap size may be determined.
 18. Thedebugging system set forth in claim 16 wherein: the memory usageinformation includes information from which the memory allocated by theexecuting program may be determined; and the read query obtains theinformation from which the memory allocated by the executing program maybe determined.
 19. The debugging system set forth in claim 16 furthercomprising: a memory leak detector used by the executing program todetect memory leaks, the memory leak detector providing an update querycontaining information from which the current amount of memory leaked bythe program may be determined; and the read query obtains theinformation from which the current amount of memory leaked by theprogram may be determined.
 20. The debugging system set forth in claim19 further comprising: command information in the debugging informationspecifying a leak detector command, the command information beingprovided to the debug data base system by an update query from theinteractive interface, being read from the debug data base system by aread query from the memory allocator, and the memory allocatorresponding to the leak detector command by causing execution of thememory leak detector.
 21. The debugging system set forth in claim 16wherein: the debugging information persists after the executing programhas ceased executing; and the interactive interface further responds tothe input from the user by providing a read query on the persistentdebugging information after the executing program has ceased executing.22. The debugging system set forth in claim 21 wherein: the persistentdebugging information includes persistent debugging information for aplurality of executions of the program; and the input selects persistentdebugging information from an execution of the plurality thereof. 23.The debugging system set forth in claim 22 wherein: the input furtherspecifies one of a plurality of views of the debugging information; andthe interactive interface responds to the input by providing the readquery as required for the view specified in the input.
 24. The debuggingsystem set forth in claim 23 wherein: the plurality of views include aview that shows the memory allocated during the execution.
 25. Thedebugging system set forth in claim 23 wherein: the debugging systemfurther includes a memory leak detector used by the executing program todetect memory leaks, the memory leak detector providing update queriescontaining information from which the memory leaked by the program maybe determined; and the plurality of views include a view that shows thememory leaked during the execution.
 26. The interactive debugging systemset forth in claim 16 wherein: the interactive interface is associatedwith a universal resource indicator, receives a first message accordingto the http protocol which is directed to the associated universalresource indicator, and responds to the first message by sending asecond message according to the http protocol, the first messagecontaining the input from the user to the interactive interface and thesecond message containing the formatted results.
 27. The interactivedebugging system set forth in claim 26 wherein: the interactiveinterface is part of a given computer system; and the source of thefirst message and the destination of the second message are in thealternative local to the given computer system or remote therefrom. 28.A storage device for storing digital information, the storage devicebeing characterized in that: the storage device contains a programwhich, when executed in a computer system, implements the interactivedebugging system set forth in claim 16.